Size Change: -8 B (0%)

Total Size: 1.69 MB

_{compressed-size-action}

Flaky tests detected in f35b97c.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7302253510
📝 Reported issues:

• [Flaky Test] Should show Columns block only if selected blocks are between limits (1-6) #40369 in specs/editor/various/block-switcher.test.js

Thank you for your feedback, @andrewserong!

Mostly, what I'm wondering is how could we simplify the API for it so that if and when we want to allow 3rd party blocks to expose images in the list view, it'd be as simple as possible for them to do so.

I was also concerned about this. While this PR approach gives us the flexibility to expose list view image sources, it can be a bit unintuitive, especially for third-party block developers😅

What I had in mind was if it'd be possible to have something in block.json that specifies where to look for the block image. So the Image block might reference the image's id or external url, and the Gallery block might specify "children" or "innerBlocks" so that the list view knows to iterate over the first x number of blocks within the block in order to grab the image urls. That approach might have its own drawbacks or blockers, too.

Ideally, this would certainly be easier to understand and use. For example, if we want to expose the url attribute as a list view image, we might define it like this:

{
	"name": "core/image",
	"supports": {
		"listViewImage": {
			"attribute": "url"
		}
	}
}

Or if we want to convert to image URL based on media Id:

{
	"name": "core/image",
	"supports": {
		"listViewImage": {
			"attribute": "id",
			"type": "mediaId"
		}
	}
}

Or if we want to expose list view images based on child block attributes in the Group block:

{
	"name": "core/group",
	"supports": {
		"listViewImage": {
			"type": "children",
			"blocks": [ "core/image" ],
			"attribute": "url"
		}
	}
}

I'd like to hear everyone's opinions on what approach is best.

Nice idea, and I agree with @andrewserong's comments here, I think if we are to add an API here, it should be something declarative in the register block function rather than a state.

In a sense, the "image" is just another representation of a block (attributes) => output and we already have 4 or 5 of them.

• edit function represents the block in the editor block list
• save represents the block in the saved markup
• __experimentalLabel (which we should consider just making it stable at some point) to represent the block in "list view" or as a string.

I'm sure I'm forgetting more, but it seems we may need thumbnail that just returns a "thumbnail" based on the block, it might not be a simple image, it could be a React element...

Now, we already have context = "list view" in the experimentalLabel config and we already have alternative things like anchors visible there, images...

I guess what I'm saying is that we should keep in mind all these precedents and think about something more generic if possible, if not, using the same approach and add a thumbnail property to the block registration maybe.

Thank you for your opinions, @andrewserong and @youknowriad. So, I'd like to close this PR and explore an approach to opt-in declaratively via block.json or a property similar to __experimentalLabel when I have time 👍